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Foreword 



This Technical Specification (TS) has been produced by the Joint Technical Committee (JTC) Broadcast of the 
European Broadcasting Union (EBU), Comite Europeen de Normalisation ELECtrotechnique (CENELEC) and the 
European Telecommunications Standards Institute (ETSI). 

NOTE 1 : The EBU/ETSI JTC Broadcast was established in 1990 to co-ordinate the drafting of standards in the 
specific field of broadcasting and related fields. Since 1995 the JTC Broadcast became a tripartite body 
by including in the Memorandum of Understanding also CENELEC, which is responsible for the 
standardization of radio and television receivers. The EBU is a professional association of broadcasting 
organizations whose work includes the co-ordination of its members' activities in the technical, legal, 
programme-making and programme-exchange domains. The EBU has active members in about 60 
countries in the European broadcasting area; its headquarters is in Geneva. 

European Broadcasting Union 

CH-1218 GRAND SACONNEX (Geneva) 

Switzerland 

Tel: +41 22 717 21 11 

Fax: +4122 717 24 81 

The Eureka Project 147 was established in 1987, with funding from the European Commission, to develop a system for 
the broadcasting of audio and data to fixed, portable or mobile receivers. Their work resulted in the publication of 
European Standard, ETS 300 401 [2], for DAB (see note) which now has worldwide acceptance. The members of the 
Eureka Project 147 are drawn from broadcasting organizations and telecommunication providers together with 
companies from the professional and consumer electronics industry. 

NOTE 2: DAB is a registered trademark owned by one of the Eureka Project 147 partners. 
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Scope 



The present document covers the core Digital Audio Broadcasting (DAB) requirements to enable interactive services 
supporting broadcasting to mobile, portable and fixed receivers with narrowband return channels. 

The system defined in the present document provides a variety of generic solutions for a variety of future interactive 
services, through the adoption of the MOT protocol (specific for DAB) and the IP protocol. 

The interactive services are provided on systems consisting of a high bitrate downstream channel (up to the maximum 
bitrate of the broadcast channel) from the service providers to service consumers and low bitrate interaction channels. 
The Broadcast service provider and the interactive service provider need not operate from the same location 
(see figure 2). 

The services are seen from DAB Program Associated Data (PAD) enhanced and standalone (packet mode) data 
broadcasting services with interactivity. At the simplest level the interactive channel allows the consumer to react by 
voting, to order articles displayed in the broadcast or make reservations of hotel rooms, restaurant tables, etc. It is also 
possible to deliver text, graphics, audio and still pictures (including e-mail) on-demand, both via the broadcast channel 
and the interaction channel. 

There are many possible network configurations covering the currently specified DAB broadcast options including 
terrestrial, satellite and cable in conjunction with GSM, PSTN, ISDN, DECT and other interactive channel options. The 
specification of the network dependent protocols are specified within TS 101 737 [3]. 

In the process of producing the present document the specifications for an interaction channel for Digital Video 
Broadcasting (DVB) has carefully been studied. The goal has been to as far as possible be compatible with the DVB 
solutions thereby creating a common concept of treating the combination broadcast-Aelecommunicationsystem. 
Although the use of existing DAB data transfer protocols for the broadcast channel, when appropriate, has been essential 
in the writing of the present document. 
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Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

BC Broadcast Channel 

CHAP Challenge Handshake Authentication Protocol 

DAB Digital Audio Broadcasting 

DAB-RM Digital Audio Broadcasting - Receiver Module 

DECT Digital Enhanced Cordless Telecommunications 

DVB Digital Video Broadcasting 

Eld Ensemble Identifier 

EUA End User Address 

FBC Feed Back Channel 

FTP File Transfer Protocol 

GSM Global System for Mobile communication 

HTTP Hyper Text Transfer Protocol 

IC Interaction Channel 

IETF/RFC Internet Engineering Task Force/Request For Comments 

IM Interaction Module 

IP Internet Protocol 

IPCP Internet Protocol Control Protocol 

ISDN Integrated Services Digital Network 

LCP Link Control Protocol 

MMI Man Machine Interface 

MOT Multimedia Object Transfer protocol 

MSC Main Service Channel 

NCU Network Control Unit 

OSI Open Systems Interconnection 

PAD Programme Associated Data 

PAP Password Authentication Protocol 

POP3 Post Office Protocol 
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PPP Point-to-Point Protocol 

PSSC Personal Service Session Control protocol 

PSTN Public Switched Telephone Network 

SCId Service Component Identifier 

Sid Service Identifier 

SMS Short Message Service 

TCP Transmission Control Protocol 

UDP User Datagram Protocol 

UT User Terminal 

X-PAD Extended Programme Associated Data 



Reference models 



4.1 



Protocol stack model 



For asymmetric interactive services supporting broadcast to mobile/portable/stationary receivers with a narrowband 
return channel, a simple communication model consists of the following layers: 

application layer: is the interactive application software and runtime environments (e.g. home shopping application, 
script interpreter, etc.). 

transport layer: defines all the relevant data structures and communication protocols. 

physical layer: where all the physical (electrical) transmission parameters are defined. 

The present document addresses the lower two layers (the physical and transport) leaving the application layer open to 
competitive market forces. It is not the role of the present document to define standardized applications. 

A simplified model of the OSI layers is adopted to facilitate the production of specifications for these nodes. Figure 1 
points out the lower layers of the simplified model and identifies some of the key parameters for the lower two layers. 
Following the user requirements for interactive services, no attempt will be made to consider higher layers in the present 
document. 
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Layer Structure for Generic System Reference Model 



Proprietary 
layers 



Higher medium 
layers 



Access 
mechanism 
Packet Structure 



Modulation 
Channel Coding 
Freq. Range 
Filtering 
Equalisation 
Power 



Network Independent 
Protocols 



Network Dependent 
Protocols 



Figure 1 : Layer structure for generic system reference model 



4.2 System model 



Figure 2 shows the system model which is to be used within DAB for interactive services. 

In the system model, two channels are established between the service provider and the end user: 

Broadcast Channel (BC): an unidirectional broadband broadcast channel that can include audio, low bit-rate video and 
different types of data. BC is established from the service provider to the end users. It may include the forward 
interaction path in other words distributing individually addressed data to the end user. 

Interaction Channel (IC): a bi-directional interaction channel is established between the service provider and the end 
user for interaction purposes. It is formed by: 

return interaction path (return channel): from the end user to the service provider. It is used for instance to 
make requests to the service provider or to answer questions. In most cases it is a narrow-band channel also 
commonly known as return channel; 

forward interaction path: from the service provider to the end user. It is used to provide some sort of 
individually addressed information by the service provider to the end user and any other required communication 
for the interactive service provision. It may be embedded into the broadcast channel. It is possible that this 
channel is not required in some simple implementations which make use of the broadcast channel for the carriage 
of data to the end user. 

The UT is formed by the DAB Receiver Module (DAB-RM), the Interaction Module (IM), the Man Machine Interface 
(MMI) and the application module. The UT provides interface for both broadcast and interaction channels. The 
interface between the UT and the interaction network is via the interaction module. 
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The interface between the broadcast channels and the user terminal is via the DAB receiver module. 
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Figure 2: A generic system reference model for interactive systems based on DAB 



Protocol stacks 



5.1 



General 



This subclause describes the different protocol stacks for the broadcast channel and the interaction channel that should 
be used in order to implement an interactive DAB service. Guidelines of which protocols that are suitable for specific 
types of interactive services are found in annex A of the present document. 



5.2 Content transport - data 



5.2.1 



Broadcast channel 



Two categories of data transport are provided/recommended for the DAB channel depending on if the DAB channel is 
used for broadcast or individually addressed information. 

(i) DAB specified transmission system with MOT. 

Table 1 : Protocol stack for MOT via broadcast channel 



Higher layers 


MOT 


Packet mode 
(MSC Data groups) 


MOT 
(X-PAD Data groups) 


Packet mode 
(packets) 


X-PAD 
(data sub-fields) 


DAB-MSC 



The Multimedia Object Transport (MOT) protocol as specified in EN 301 234 [1] and DAB-MSC, packet mode and 
X-PAD protocols as specified in ETS 300 401 [2]. 

(ii) DAB with UDP/IP or TCP/IP. 
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Table 2: Protocol stack for TCP/IP or UDP/IP via broadcast channel 



Higher layers 



TCP 



UDP 



IP 



Packet mode (MSC data Groups) 



Packet mode (packets) 



DAB-MSC 



The mechanism for tunnelling IP datagrams within DAB is specified in TS 101 735 [5] and the DAB-MSC and Packet 
mode protocols are specified in ETS 300 401 [2]. The TCP is specified in IETF/RFC 793 [8], UDP in 
IETF/RFC 768 [6] and IP in IETF/RFC 791 [7]. 

In the case of the use of TCP an interaction channel is mandatory since the TCP protocol requires a flow of return 
acknowledgements. UDP does not use return acknowledgements and thus does not require an IC to work on the 
transport layer, however higher layer protocols using UDP may require an IC (return acknowledgements). 

The definition of the higher layer protocols are not within the scope of the present document. However, the standard 
TCP/IP-family application layer protocols such as IETF/RFC 959 [12], IETF/RFC 1725 [14], IETF/RFC 2068 [16], as 
well as application specific proprietary protocols may be used to implement the higher layer protocols. 

5.2.2 Interaction channel 

Two different protocol stacks are provided for the two main different types of interaction on the IC. 
(i) One-way interaction and two-way interaction (personal FBC services). 

Table 3: Protocol stack for the interaction channel concerning one-way interaction 
and two-way interaction with personal FBC services 



Higher layers 


TCP 


UDP 


SMS 


IP 


SMS 


PPP 


other 


SMS 


GSM, PSTN, ISDN, DECT 


other network 


GSM 



(ii) Two-way interaction (personal DAB services). 

Table 4: Protocol stack of the interaction channel (return path) for personal DAB services 



Higher layers 


TCP 


UDP 


IP 


PPP 


other 


PSTN, ISDN, GSM, DECT 


other network 



The TCP is specified in IETF/RFC 793 [8], UDP in IETF/RFC 768 [6], IP in IETF/RFC 791 [7] and PPP in 
IETF/RFC 1661 [10]. 

When carrying TCP over the broadcast channel, an interaction channel shall be established for the flow of return 
acknowledgements. Standard TCP is adequate for delivery of content up to 150 kbit/s in secure bi-directional networks. 
If TCP is required to deliver data at a higher rate, work over non secure radio interfaces or on top of long delay network 
extensions to or special implementations of TCP are recommended. These implementations are backwards compatible 
with standard TCP implementations but optimize TCP to the existing situation. If this option is used the extensions of 
TCP shall be according to IETF/RFC 1332 [9]. 

Information about how the GSM Short Message Service (SMS) is used are give in GSM 03.38 [18] and 
GSM 03.40 [17]. 
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The definition of the higher layer protocols are not within the scope of the present document. However, the standard 
TCP/IP-family application layer protocols such IETF/RFC 959 [12], IETF/RFC 1725 [14], IETF/RFC 2068 [16]..., as 
well as application specific proprietary protocols may be used to implement the higher layer protocols. 

The specification of the network dependent protocols are specified within TS 101 737 [3]. 

5.3 Session control signalling 

5.3.1 One-way interaction 

The co-ordination of the data flow between the DAB channel and the interaction channel is subject for higher layer 
protocols and therefore not defined in the present document. 

5.3.2 Two-way interaction with personal FBC services 

The co-ordination of the data flow between the DAB channel and the interaction channel is subject for higher layer 
protocols and therefore not defined in the present document. 

5.3.3 Two-way interaction with personal DAB services 

In order to be able to establish a two-way interaction with a personal DAB service session it is necessary to do session 
control signalling to co-ordinate the data flow between the broadcast channel and the interaction channel. All session 
control signalling is done within the interaction channel and is bi-directional. The use of session control signalling is 
specified in clause 8 of the present document. 

The session control signalling is made by sending PSSC messages in TCP or UDP over the interaction channel between 
the UT and the Network Control Unit (NCU). The PSSC message format is specified in clause 9 of the present 
document. On the NCU TCP or UDP port number 645 shall be used for session control signalling. 

Table 5: Protocol stack for session control signalling for two-way interaction 
with forward interaction path within the broadcast channel 



PSSC 


TCP 


UDP 


IP 


PPP 


other 


PSTN, ISDN, GSM, DECT 


other network 



The TCP is specified in IETF/RFC 793 [8], UDP in IETF/RFC 768 [6], IP in IETF/RFC 791 [7] and PPP in 
IETF/RFC 1661 [10]. 

The specification of the network dependent protocols are specified within TS 101 737 [3]. 

5.4 Connection control signalling 

Network dependent so not defined in the present document. The specification of the network dependent protocols are 
specified within TS 101 737 [3]. 
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PPP data link set-up 



6.1 General 

After the user terminal has been connected through the interaction network to the network server, the PPP configuration 
process is initiated. This configuration process consists of the following phases: 

1) Link Control Protocol (LCP, see IETF/RFC 1661 [10]) is used to establish the data link connection; 

2) IPCP (IETF/RFC 1332 [9]) is used to configure IP and the type of compression. 

In phase 1) and 2), both "configure-request" and "configure-ack" packets are sent and received. In phase 2), the user 
terminal sends a configure-request packet that includes the IP address configuration fields at the beginning. In this case, 
PPP facilitates the transfer of an IP address from the interactive service provider during the initialization phase of PPP. 

Authentication of the UT shall be done during data link set-up. The authentication can be done using the Password 
Authentication Protocol (PAP) and Challenge Handshake Authentication Protocol (CHAP), both as specified in 
IETF/RFC 1994 [15]. It also exists other authentication protocols that may be used. 

6.2 PPP configuration for IP transmission 

For compression of the IP address and control fields (see IETF/RFC 1332 [9]), the following protocols shall be 
supported in the PPP data link layer: 

0021 internet protocol; 

002d Van Jacobson compressed TCP/IP; 

002f Van Jacobson uncompressed TCP/IP. 

For the PPP link, the following configuration shall be supported as recommended for PSTN type links 
(see IETF/RFC 1332 [9]): 

async control character map; 

magic number; 

address and control field compression; 

- protocol field compression. 



TCP connection set-up 



When TCP is used as transport layer protocol the TCP connection shall be established as specified in 
IETF/RFC 793 [8]. 

The port numbers to use should specified in the higher layer protocol. See also IETF/RFC 1700 [13] for information of 
assigned port numbers. 
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8 Session control in personal DAB services 



8.1 



General 



Session control is needed for personal DAB services to co-ordinate the data flow between the broadcast channel and the 
interaction channel. The personal DAB service session control signalling is done between the user terminal and the 
network control unit. Only one PSSC session is allowed for each UT. All session control signalling is done within the 
interaction channel and is bi-directional. If the session control protocol is used, the protocol stack shall be as defined in 
subclause 5.3.3 of the present document. 

All session control signalling is done with PSSC messages which are described in clause 9. The signal flow of the PSSC 
messages is described in subclauses 8.2 to 8.5. 

In parallel to the PSSC session there will be one or more sessions between the client applications in the UT and the 
server applications in the service provider servers. These UT to service provider application sessions are the ones that 
are involved with the user interaction and data transfer in the service. The relationship between the PSSC session and the 
application sessions is described in figure 3. 



Service 

Provider 

Server 



Server 
Application 




Application Sessions 




PSSC 

Session 



Terminal 



Client 
Application 



DAB 

receiver 
module 



Figure 3: Relationship between PSSC session and application sessions 



8.2 



Session establishment 



When an user terminal wants to establish a personal DAB service session, using TCP for PSSC transport, it first 
establishes a TCP connection to the network control unit TCP port number 645. After this connection has been 
established the client-initiated session set-up sequence described in figure 4 takes place. If UDP is used for PSSC 
transport, the datagrams containing PSSC messages shall be sent to the UDP port number 645 on the NCU. 
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Terminal 



Network 
Control 



Tcsf 



V 



ClientSetupRequest 

(protocol, currentEId, EUAfix, EId_list, TII_list) 



ClientSetupConfirm 

(Eld, Sid, SCId, EUAdyn, timer list) 



ClientSetupDenial 

(errorMsg ) 
i^. 



Clients etupConnect ( ) 



ClientSetupFailure 
(errorMsg) 



LCSC 



NOTE: 



V 



If the NCU has an out standing ServerSetupRequest to the user terminal at the time when the 
ClientSetupRequest is received, the ClientSetupRequest shall be denied. If such situation occurs both 
parts shall wait a random time before they retry to establish a PSSC session. 



Figure 4: Client initiated session set-up sequence 

If the network wants to establish a personal DAB service session, using TCP for PSSC transport, it first establishes a 
TCP connection from the NCU unit to user terminal TCP port number 645. When this connection has been established 
the server-initiated session set-up sequence described in figure 5 takes place. If UDP is used for PSSC transport, the 
datagrams containing PSSC messages shall be sent to the UDP port number 645 on the user terminal. 

NOTE: Server initiated session set-up is an optional feature that might not be supported by all user terminals. 
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Terminal 



Network 
Control 



Tssa 



ServerSetupRequest 
^ (protocol, timer list) 




ServerSetupAccept 

(currentEId, EUAfix, Eldjist, THJist) 




ServerSetupDenial 
(errorMsg ) 




ServerSetupConfirm 
(Eld, Sid, SCId, EUAdyn) 


V 


ServerSetupAbbort 
(errorMsg ) 




V 

ServerSetupConnect ( ) 




ServerSetupFailure 
(errorMsg) 






V 



T s 



SR 



T s 



sc 



NOTE: If the UT has an out standing ClientSetupRequest to the NCU at the time when the ServertSetupRequest 
is received, the ServerSetupRequest shall be denied. If such situation occurs both parts shall wait a 
random time before they retry to establish a PSSC session. 

Figure 5: Server initiated session set-up sequence 



8.3 



Session release 



When the user terminal wants to close the session, it uses the client-initiated session release sequence in figure 6. After 
that, the connection can be closed. After the network control unit has received the ClientReleaseRequest message, it can 
close all objects related to the session and shut down the service for the session. 



Terminal 



Network 
Control 



ClientReleaseRequest ( ) 



Figure 6: Client-initiated session release sequence 

If the network wants to close the session, it uses the server-initiated session release sequence in figure 7. After that, the 
connection can be closed. After the terminal has received the ServerReleaseRequest message, it can close all objects 
related to the session. 
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Terminal 



Network 
Control 



ServerReleaseRequest ( ) 



Figure 7: Server initiated session release sequence 



8.4 Alive checking 



If the user terminal wants to check that it still has contact with the network control unit it sends a 
ClientServeraliveCheck message. When the NCU receives a ClientServeraliveCheck message it will respond with a 
ClientServeraliveConfirm message. When the UT receives that message it will know that the PSSC session is still alive. 
If no ClientServeraliveConfirm message is received by the UT before the timer T C s a c expires the user terminal will 
assume that the session is dead and close the connection. This client initiated alive check sequence is shown in figure 8. 



Terminal 



Network 
Control 



-CSaC 



V 



ClientServeraliveCheck ( ) 



ClientServeraliveConfirm( ) 



Figure 8: Client initiated alive check sequence 

If the network control unit wants to check that it still has contact with the user terminal it sends a 
ServerClientaliveCheck message. When the UT receives a ServerClientaliveCheck message it will respond with a 
ServerClientliveConfirm message. When the NCU receives that message it will know that the PSSC session is still alive. 
If no ServerClientaliveConfirm message is received by the UT before the timer T SCaC expires the NCU will assume that 
the session is dead and close the connection. This client initiated alive check sequence is shown in figure 9. 
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Terminal 



Network 
Control 



ServerClientaliveCheck ( ) 



SeverClientaliveConfirm( ) 



TsCaC 



V 



Figure 9: Server initiated alive check sequence 



8.5 



Handover 



If the user terminal moves out of the coverage area for the DAB ensemble that it is currently tuned to it has to re-tune to 
another ensemble carrying the same personal DAB service. Before the UT can re-tune it has to inform and negotiate 
with the network about what ensemble to re-tune to. When that decision of new ensemble is made the UT re-tunes and 
the network re-routes to the new ensemble. This handover is controlled by the client-initiated handover sequence 
described in figure 10. 



Terminal 



Network 
Control 



TcHR 



V 



ClientHandoverRequest 
(Eldjist, THJist) 



ClientHandoverConfirm 

(Eld, Sid, SCId, EUAdyn, timer list) 



ClientHandoverDenial 
(errorMsg ) 



ClientHandoverConnect ( ) 



ClientHandoverFailure 
(errorMsg) 



-CHC 



V 



Figure 10: Client-initiated handover sequence 

There are also cases when the network will initialize handover. This handover is controlled by the server-initiated 
handover sequence described in figure 1 1 . 
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Terminal 



Network 
Control 



T s 



HA 



V 



ServerHandoverRequest 

(timer list) 



ServerHandoverAccept 
(Eldjist, THJist) 



ServerHandoverDenial 
(errorMsg ) 



ServerHandoverConfirm 
(Eld, Sid, SCId, EUAdyn) 



S erverH andover Abort 
(errorMsg ) 



ServerHandoverConnect ( ) 



ServerHandoverFailure 
(errorMsg) 



Tshr 



V 



LSHC 



V 



Figure 11 : Server-initiated handover sequence 



8.6 Temporary download through interaction channel 

If the network looses DAB coverage it can order the network to re-route the download to the interaction channel. This is 
done by sending a ClientSignalLost to the network control unit. The network stops the download through DAB and 
confirms that the download will be done through the IC with a ClientlSignalChange message. If the network is not able 
to re-route the download to the IC it will signal this with an ClientSignalDenial message. This signalling sequence is 
described in figure 12. 

When the terminal gets DAB coverage again it can ask the network to re-route download to DAB by using the 
client-initiated handover sequence. 
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Terminal 



Network 
Control 





Clients 


gnalLost () 








ClientSignalChange () 








ClientSignalDenial 
(errorMsg ) 














V 











Figure 12: Client-initiated request for download through IC due to loss of DAB signal 



9.1 



PSSC message format 



General 



The general data structure of the PSSC messages is formed as in figure 13. The PSSC message consist of a PSSC header 
and to 255 PSSC parameter fields. 



24 bits 



variable 



variable 



Header 



Parameter field 1 



Parameter field n 



Figure 13: Data structure of the PSSC messages 



9.2 



PSSC header 



The PSSC header is 24-bits long and the data structure is defined according to figure 14. 



1 bit 



7 bits 



8 bits 



8 bits 



c/s 

flag 


Message 
type 


Message 
subtype 


Number of 
parameters 



Figure 14: Data structure of the PSSC messages header field 

Client/Server Initiation Flag (C/S flag): this 1-bit field indicates if the signalling sequence is initiated by the client 
(user terminal) or the server (network control unit) entity: 

0: signalling sequence is initiated by the client (UT); 

1: signalling sequence is initiated by the server (NCU). 
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Message type field: this 7-bit field specifies which PSSC sequence (see clause 8) the message belongs to. The 
interpretation of this field is specified in table 6. 

Message subtype field: this 8-bit field specifies which message in the PSSC sequence that is carried. The interpretation 
of this field depends on the value of the message type field and is specified in table 6. 

NOTE: The Rfu values of table 6 may be defined within TS 101 756 [4], without a formal update of the present 
document. 

Table 6: Interpretation of message type field and message subtype field 



Message type field 


Message type name 


Message subtype field 


Message subtype name 


0000000 


Set-up 


00000000 


Request 






00000001 


Accept 






00000010 


Confirm 






0000001 1 


Connect 






10000001 


Denial 






10000010 


Failure 






10000011 


Abort 






other 


Rfu 


0000001 


Release 


00000000 


Request 






other 


Rfu 


0000010 


Client/Server-alive 


00000000 


Check 






00000001 


Confirm 






other 


Rfu 


0000011 


Handover 


00000000 


Request 






00000001 


Accept 






00000010 


Confirm 






0000001 1 


Connect 






10000001 


Denial 






10000010 


Failure 






10000011 


Abort 






other 


Rfu 


0000100 


Signal 


00000000 


Lost 






00000001 


Change 






10000001 


Denial 






other 


Rfu 


1000000 


Proprietary signalling 


all 


proprietary 


1111111 








other 


Rfu 


all 


Rfu 



Number of parameters field: this 8-bit field contains a binary encode unsigned integer (0 - 255) that indicates the 
number of PSSC parameter fields carried in the PSSC message. 

9.3 PSSC parameter fields formats 
9.3.1 General data structure of parameter fields 

The structure of the parameter field is defined in figure 15. 

6 bits 1 bit 1 bit 8 or 1 6 bits n x 8 bits 



Parameter 
Identifier 


R/O 
flag 


Ext. 
flag 


Data field length 
indicator, n 


Data field 



Figure 15: Data structure of PSSC parameter field 

Parameter identifier: this 6-bit field identifies the type of parameter. The coding of the parameter types is defined in 
table 7. 
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NOTE: The Rfu values of table 7 may be defined within TS 101 756 [4], without a formal update of the present 
document. 

Table 7: Interpretation of parameter identifier field 



Parameter 
identifier 


Parameter name 


R/O flag 


Data filed 
length 


Interpretation 


000000 


DAB protocol 





1 byte 


see subclause 9.3.2, D1 


000001 


Ensemble identifier 





2 byte 


see subclause 9.3.2, D2 


000010 


Service identifier 





2 byte 


see subclause 9.3.2, D3 


00001 1 


Service component identifier 





2 byte 


see subclause 9.3.2, D4 


000100 


End user address 





variable 


see subclause 9.3.2, D5 


000101 


Ensemble identifier list 





variable 


see subclause 9.3.2, D6 


000110 


Transmitter identification 
information list 


0/1 


variable 


see subclause 9.3.2, D7 


0001 1 1 


Text message 


0/1 


variable 


see subclause 9.3.2, D8 


001000 


Timer list 


0/1 


variable 


see subclause 9.3.2, D9 


001001 
011111 


Rfu 


not specified 


not specified 


not specified 


100000 

111111 


Proprietary parameter 


0/1 


proprietary 


proprietary 



R/O Flag (Required/Optional flag): this 1-bit field indicates how the receiving part shall handle a unrecognized 
parameter identifier. The following definitions applies: 

0: the parameter is required for the functionality of this PSSC message. Ignore the whole PSSC message if 
parameter identifier is unrecognized; 

1 : the parameter is optional (not required) for the functionality of this PSSC message. Ignore only this parameter if 
parameter identifier is unrecognized. 

The allowed values of the R/O flag are listed in table 7. 

Ext. Flag (Extension Flag): this 1-bit field specifies the length of the data field length indicator and is coded as 
follows: 

0: the data field length indicator is 8 bits long; 

1: the data field length indicator is 16 bits long. 

Data field length indicator: this field specifies as an unsigned binary integer the length of the data field in bytes. The 
length of the field is either 8 or 16 bits depending on the value of the extension flag. 

Data field: this field contains the parameter data as specified in subclause 9.3.2. The length of the field is variable and 
signalled in the data field length indicator. 

9.3.2 Data field structure of parameter field 

Dl. DAB Protocol: 8-bit data field that contains information about which protocols that shall be used in the broadcast 
channel during a personal DAB session. This field is used to carry protocol parameter in the session signalling described 
in clause 8 of the present document. The protocol parameter is encoded as follows: 

0000000 0: MOT in packet mode (see EN 301 234 [1]); 

00000001: IP datagram tunnelling in packet mode (see TS 101 735 [5]); 

other: Rfu. 

NOTE: The Rfu values of the DAB protocol field may be defined within TS 101 756 [4], without a formal update 
of the present document. 
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D2. Ensemble Identifier (Eld): 16-bit field that contains an ensemble identifier as specified in ETS 300 401 [2], This 
field is used to carry the current Eld and the Eld parameters in the session signalling described in clause 8 of the present 
document. 

D3. Service Identifier (Sid): 32-bit field that contains a 32-bit service identifier as specified in ETS 300 401 [2]. This 
field is used to carry the Sid parameter in the session signalling described in clause 8 of the present document. 

D4. Service Component Identifier (SCId): the 12 least significant bits of this 16-bit field contains a service 
Component identifier as specified in ETS 300 401 [2], The 4 most significant bits are Rfu and shall be set to 0. 
This field is used to carry the SCId parameter in the session signalling described in clause 8 of the present document. 



4 bits 



1 2 bits 



Rfu 


SCId 



Figure 16: Data structure of the service component identifier parameter field 

D5. End User Address (EUA): a n x 8 bit field that contains the end user address of the user terminal. The number of 
octets, n, in the field is equal to the value of the data field length indicator specified in subclause 9.3.1. For EUA only 
the data field length indicator values in the interval 1 to 15 are legal. This field is used to carry the EUA parameter in the 
session signalling described in clause 8 of the present document. 

D6. Ensemble Identifier List (Eid List): a m x 16 bit field that contains a list of m Eld's (as specified in 
ETS 300 401 [2]) of ensembles available for the user terminal. The number of sub-fields, m in the Eld list is equal to 
half the value of the data field length indicator specified in subclause 9.3.1. The order of the Eld in the list gives their 
priority. The first Eld in the list has highest priority. This field is used to carry the Eld list parameter in the session 
signalling described in clause 8 of the present document. 



1 6 bits 



1 6 bits 



Eld 1 



Eld AT? 



Figure 17: Data structure of the ensemble identifier List parameter field 

D7. Transmitter Identification Information List (Til list): aix 16 bit field that contains a list of i Til of transmitters 
available for the terminal. The Til's are derived from the DAB synchronization channel as specified in ETS 300 401 [2]. 
The number of sub-fields, /, in the Til list is equal to half the value of the data field length indicator specified in 
subclause 9.3.1. The order of the Til in the list gives their priority. The first Til in the list has highest priority. This field 
is used to carry the Til list parameter in the session signalling described in clause 8 of the present document. 



1 6 bits 



1 6 bits 



Til 1 



Til / 



Figure 18: Data structure of the transmitter identification information list parameter field 

The Til sub-fields in the list are defined by figure 19. The c field contains the comb number c as defined in 

ETS 300 401 [2]. The/? field contains the pattern number/? as defined in ETS 300 401 [2]. The c and/? are coded as 

unsigned binary numbers with the following values: 

- < c < 23 

< p < 69 for DAB transmission mode I, II and IV 

< p < 5 for DAB transmission mode III 

All other values of c and p shall be regarded as illegal. 
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8 bits 



8 bits 



c 


p 



Figure 19: Data structure of the transmitter identification Information carried in the Til sub-fields 



D8. Text Message field (TxtMsg): ay x 8 bit field used to carry a j character long text string. The number of characters, 
j, in the field is equal to the value of the data field length indicator specified in subclause 9.3.1. The characters shall be 
encoded in the ISO Latin Alphabet No 1, see ISO/IEC 8859-1 [11]. 

The text string can be used for error messages or other messages that may displayed by the terminal. The TxtMsg can be 
used as an optional parameter to all messages in the PSSC protocol. 



8 bits 



char 1 



8 bits 



8 bits 



char 2 



chary 



Figure 20: Data structure of the text field parameter field 

D9. Timer list: a k x 16 bit field that carries a list of k timers that can be downloaded to the terminal from the network 
as described in clause 8. The number of sub-fields, k, in the timer list is equal to half the value of the data field length 
indicator specified in subclause 9.3.1. 



1 6 bits 



1 6 bits 



Timer 1 



Timer k 



Figure 21 : Data structure of the timer list parameter field 

The structure of the timer sub-fields is defined in figure 22. The Timerld indicates which timer, in clause 8, the timer 
value reefers to. The interpretation of the Timerld is specified in table 8. The timer value carries the time out time for 
the timer in seconds, coded as a 8 bit unsigned binary number. The timer value 00000000 has the special meaning of 
undefined and indicates that the user terminal shall set this value by it self. 

NOTE: The Rfu values of table 8 may be defined within TS 101 756 [4], without a formal update of the present 
document. 



8 bits 



8 bits 



Timerld 


Timer value 



Figure 22: Data structure of the timer information carried in the timer sub-fields 
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Table 8: Interpretation of Timerld 



Timer Id 


Timer name 


Shortage 


Usage 


00000000 


ClientSetupRequest timer 


Tcsr 


See subclause 8.2 


00000001 


ClientSetupConfirm timer 


Tcsc 


See subclause 8.2 


00000010 


ServerSetupRequest timer 


Tssr 


See subclause 8.2 


00000011 


ServerSetupAccept timer 


Tssa 


See subclause 8.2 


00000100 


ServerSetupConfirm timer 


Tssc 


See subclause 8.2 


00000101 


ClientServeraliveCheck timer 


TcSaC 


See subclause 8.4 


00000110 


ServerClientaliveCheck timer 


TsCaC 


See subclause 8.4 


00000111 


ClientHandoverRequest timer 


TcHR 


See subclause 8.5 


00001000 


ClientHandoverConfirm timer 


Tchc 


See subclause 8.5 


00001001 


ServerHandoverRequest timer 


TsHR 


See subclause 8.5 


00001010 


ServerHandoverAccept timer 


TsHA 


See subclause 8.5 


00001011 


ServerHandoverConfirm timer 


Tshc 


See subclause 8.5 


00001100 


ClientSignalLost timer 


Tcsl 


See subclause 8.6 


10000000 

11111111 


Proprietary timers 


not 
specified 


proprietary 


other 


Rfu 


not 
specified 


not 
specified 
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Annex A (informative): 

Guidelines for choice of protocols for interactive services 



A.1 General 



When an interactive services is implemented it is necessary to choose an appropriate combination of the protocols 
specified in subclause 5.2 of the present document. A helpful tool for this choice is to evaluate the characteristics of the 
application that shall be used. This can be done by classifying the application as: 

1) local interaction: data broadcasting in DAB. No interaction channel required; 

2) one-way interaction: data broadcasting in DAB. Individual data transfer from user terminal to service provider 
via the IC; 

3) two-way interaction, personal FBC services: data broadcasting in DAB. Individual data transfer from user 
terminal to service provider and from service provider to user terminal via the IC; 

4) two-way interaction, personal DAB services: individual data transfer from service provider to user terminal via 
DAB. Individual data transfer from UT to service provider via IC. 

The subsequent parts of this appendix contains guidelines how to choose protocols for cases 2 to- 4. Case 1, local 
interactive, is not taken in account in the present document, since it does not require an interaction channel. 



A.2 One-way interaction 



For one-way interaction is it recommended to use the MOT protocol stack specified in subclause 5.2.1, table 1 for the 
broadcast channel and the protocol stack specified in subclause 5.2.2, table 3 for the interaction channel. 

NOTE: The GSM-SMS alternative for the interaction channel is suitable only for very small interaction messages. 
Each message is restricted to 160 7-bit characters or 140 8-bit characters (bytes). 



A. 3 Two-way interaction, personal FBC services 

For two-way interaction, personal FBC services is it recommended to use the MOT protocol stack specified in 
subclause 5.2.1, table 1 for the broadcast channel and the protocol stack specified in subclause 5.2.2, table 3 for the 
interaction channel. 

NOTE: The GSM-SMS alternative for the IC is suitable only for very small interaction messages. Each message is 
restricted to 160 7-bit characters or 140 8-bit characters (bytes). 



A. 4 Two-way interaction, personal DAB services 

For two-way interaction, personal DAB services two combinations of protocols may be chosen: 

1) the MOT protocol stack specified in subclause 5.2.1, table 1 for the DAB channel and the protocol stack 
specified in subclause 5.2.2, table 4 for the interaction channel; 

2) the IP -tunnelling protocol stack specified in subclause 5.2.1, table 2 for the DAB channel and the protocol stack 
specified in subclause 5.2.2, table 4 for the interaction channel. 

In the case of MOT in the DAB channel it has to be considered that the two channels do not have an common addressing 
scheme in the layers specified by the present document. This implies that the mapping of the different address in the 
broadcast and interaction channel shall be done in the higher layers. 
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In the case of IP tunnelling in DAB the IP-address can be used as the common addressing scheme for both the DAB and 
the interaction channel. 

For personal DAB services only the packet mode alternative shall be used. The PAD is not suitable for this type of 
service. This since PAD is constructed for data related to the audio program and therefore does not has any separate 
service signalling, which is required for the PSSC protocol. 

To use two-way interaction, personal DAB in a multi-frequency DAB network is it strongly recommended to use the 
PSSC protocol (see, subclause 5.3.3, clauses 8 and 9) for controlling of the personal DAB session. It is also 
recommended to use the PSSC protocol for control of these services in a single-frequency DAB network. 
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Annex B (normative): 

Guidelines for set-up and handover for personal DAB 

service sessions 



B.1 General 



In the case of PSSC is needed in order to co-ordinate the data flow between the broadcast channel and the interaction 
channel. The session control signalling is done within the IC and is bi-directional. If the session control protocol is used, 
the protocol stack shall be as defined in subclause 5.3.3 of the present document. 

If the main traffic in the DAB network is individually addressed (as for personal DAB services) it is recommended to 
use a cellular DAB networks in order to be able to serve large number of simultaneous users in the network (compare 
with transmitter networks for cellular phones), in contrast to broadcasting where SFN's are used. Cellular networks on 
the other hand generates the problem of roaming, in other words keeping track on in which cell the user currently is, and 
routing/switching, to pipe his requested information to the right transmitter/cell. There is also the problem of if the user 
is mobile and moving from the coverage area of one cell to another which creates handover. Considering handover there 
is also the requirement that the network is not allowed to drop/loose information indented to a user during handover. 

The PSSC protocol supports the solution of these problems. 



B.2 Personal DAB service session set-up 

The set-up of a personal DAB service session consists of two phases: 

1) phase 1, establishing a session control connection between the user terminal and the network control unit; 

2) phase 2, establishing the data connection between the user terminal and the service provider with DAB as 
down-link and FBC as up-link. 

The set-up procedure can be initiated by the user terminal and as an optional case by the network (service provider). 

B.2.1 Initiated by the user terminal 
B.2.1.1 Phase 1 

The UT establishes a physical and data link layer connection with the interaction network adapter over the interaction 
network. To do this the UT has to know how to address the network adapter, e.g. a phone number to a modem pool. 

If dynamic IP-addresses are used the server over the INA assigns the UT an IP address using the standard Internet 
protocol for dynamic IP assignment. 

If TCP is used for transport of PSSC the UT establish a TCP/IP connection to the NCU. 

B.2.1. 2 Phase 2 

The UT sends a PSSC ClientSetupRequest message to the NCU. This message contains information about the protocol 
the UT likes to use in DAB (packet mode IP tunnelling or packet mode MOT) and the Eld of the ensemble currently 
tuned to. If known the UT can also provide the NCU with lists of other Eld and/or Til possible to receive in the UT's 
current location. If the UT has an fixed EUA this is also sent to the NCU. 
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The NCU (roaming system) makes a decision, based on available capacity and transmitters covering the UT, and assigns 
an Eld, Sid, and SCId that the personal DAB service session will use. If dynamic assignment of EUA is used the NCU 
also assigns a EUA. This information is downloaded in the PSSC ClientSetupConfirm message through the IC to the 
user terminal. Since the optimal timer values for the PSSC protocol depends on the available channels, the NCU can 
download the valid timer values in a timer list in the ClientSetupConfirm message. If the NCU is unable to assign a 
channel for the personal DAB service session a ClientSetupDenial is downloaded containing a text string with an error 
message that can be displayed to the user. 

The UT uses the Eld, Sid, SCId to tune to the DAB channel where it can find the data with it's EUA. When tuned the 
UT sends a PSSC ClientSetupConnect message to the NCU indicating that it is ready to receive personal data over the 
DAB channel. If of some reason the UT can't find the DAB service component assigned it sends a PSSC 
ClientSetupFailue message instead of the PSSC ClientSetupConnect message to indicate that the set-up procedure 
should be aborted. 

The network and terminal can now use DAB as down-link and IC as up-link for the personal DAB service and a 
connection between the user terminal and the service provider can be established. 



B.2.2 Initiated by the network 



B.2.2.1 Phase 1 

The service provider indicates to the network control unit that it wants to connect a certain user terminal. 

The interaction network adapter establishes a physical and data link layer connection with the user terminal over the 
interaction network. To do this the user terminal has to know how to address the UT, e.g. a phone number. This address 
could be retrieved from a database or from the service provider during step 1 . 

If dynamic IP-addresses are used the server over the interaction network adapter assigns the UT an IP address using the 
standard Internet protocol for dynamic IP assignment. 

If TCP is used for transport of PSSC the NCU establish a TCP/IP connection to the UT. 

B.2.2.2 Phase 2 

The NCU then sends a PSSC ServerSetupRequest message to the UT. This message contains information about the 
protocol the UT likes to use in DAB (packet mode IP -tunnelling or packet mode MOT). Since the optimal timer values 
for the PSSC protocol depends on the available channels, the NCU can download the valid timer values in a timer list in 
the ServerSetupRequest message. 

The UT sends a PSSC ServerSetupAccept message to the NCU. This message contains information about the Eld of the 
ensemble currently tuned to. If known the UT can also provide the NCU with lists of other Eld and/or Til possible to 
receive in the UT's current location. If the UT has an fixed EUA this is also sent to the NCU. If the UT can't establish a 
personal DAB service session a ServerSetupDenial message is sent instead of the ServerSetupAccept. 

The NCU (roaming system) makes a decision, based on available capacity and transmitters covering the UT, and assigns 
an Eld, Sid, and SCId that the personal DAB service session will use. If dynamic assignment of EUA is used the NCU 
also assigns a EUA. This information is downloaded in the PSSC ServerSetupConfirm message through the IC to the 
UT. If the NCU is unable to assign a channel for the personal DAB service session a ServerSetupAbbortl is downloaded 
containing a text string with an error message that can be displayed to the user. 

The UT uses the Eld, Sid, SCId to tune to the DAB channel where it can find the data with it's EUA. When tuned the 
UT sends a PSSC ServerSetupConnect message to the NCU indicating that it is ready to receive personal data over the 
DAB channel. If of some reason the UT can't find the DAB service component assigned it sends a PSSC 
ServerSetupFailue message instead of the PSSC ServerSetupConnect message to indicate that the set-up procedure 
should be aborted. 

The network and terminal can now use DAB as down-link and IC as up-link for the personal DAB service. 
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B.3 Personal DAB service session handover 

In a cellular network it can be necessary to change DAB ensemble for the personal DAB service during a session, 
e.g. when a mobile UT moves out of the coverage area of it's current DAB transmitter. The handover is signalled with 
the PSSC protocol over the IC between the network control unit and the UT. 



B.3.1 Initiated by the user terminal 



The UT sends a PSSC ClientHandoverRequest message to the NCU. If known the UT provides the NCU with lists of 
other Eld and/or Til possible to receive in the UTs current location. 

The NCU (roaming system) makes a decision, based on available capacity and transmitters covering the UT, and assigns 
an new Eld, Sid, and SCId that the personal DAB service session will use. If dynamic assignment of EUA is used the 
NCU also assigns a new EUA. This information is downloaded in the PSSC ClientHandoverConfirm message through 
the IC to the UT. Since the optimal timer values for the PSSC protocol depends on the available channels, the NCU, as 
an option, can download the new timer values in a timer list in the ClientHandoverConfirm message. If the NCU is 
unable to assign a new channel for the personal DAB service session a ClientHandoverDenial is downloaded containing 
a text string with an error message that can be displayed to the user. When the ClientHandoverConfirm message has 
been sent the network shall pause the transmission of data over DAB to the UT to guarantee that no data is lost during 
re-tuning of the DAB receiver. 

The UT uses the Eld, Sid, SCId to re-tune to the new DAB channel where it can find the data with it's EUA. Then tuned 
the UT sends a PSSC ClientHandoverConnect message to the NCU indicating that it is ready to receive personal data 
over the new DAB channel. If of some reason the UT can't find the DAB service component assigned it sends a PSSC 
ClientHandoverFailure message instead of the PSSC ClientHandoverConnect message to indicate that the handover 
procedure should be aborted. 

When the network receives the ClientHandoverConnect message it can start down-loading data through DAB again. 



B.3.2 Initiated by the network 



The NCU sends a ServerHandoverRequest to indicate that it wants to start the handover procedure. Since the optimal 
timer values for the PSSC protocol depends on the available channels, the NCU, as an option, can download the new 
timer values in a timer list in the ServerHandoverRequest message. 

The UT sends a PSSC ServerHandoverAccept message to the NCU. If known the UT provides the NCU with lists of 
other Eld and/or Til possible to receive in the UTs current location. If the UT can't accept a handover a 
ServerHandoverDenial is sent. 

The NCU (roaming system) makes a decision, based on available capacity and transmitters covering the UT, and assigns 
an new Eld, Sid, and SCId that the personal DAB service session will use. If dynamic assignment of EUA is used the 
NCU also assigns a new EUA. This information is downloaded in the PSSC SeverHandoverConfirm message through 
the IC to the UT. If the NCU is unable to assign a new channel for the personal DAB service session a 
SeverHandoverAbbort is downloaded containing a text string with an error message that can be displayed to the user. 
When the SeverHandoverConfirm message has been sent the network shall pause the transmission of data over DAB to 
the UT to guarantee that no data is lost during re-tuning of the DAB receiver. 

The UT uses the Eld, Sid, SCId to re-tune to the new DAB channel where it can find the data with it's EUA. When 
tuned the UT sends a PSSC SeverHandoverConnect message to the NCU indicating that it is ready to receive personal 
data over the new DAB channel. If of some reason the UT can't find the DAB service component assigned it sends a 
PSSC SeverHandoverFailure message instead of the PSSC SeverHandoverConnect message to indicate that the 
handover procedure should be aborted. 

When the network receives the SeverHandoverConnect message it can start down-loading data through DAB again. 
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